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(54) Method and system for transmission of headerless data packets over a wireless link 



(57) Headerless (i.e., zero byte) data packets are 
sent by a compressor over a radio bearer. The radio 
bearer includes a synchronized wireless link. A sequen- 
tial timer-based value is associated with each of the 
headerless data packets. A decompressor generates a 
header based on the sequential timer-based value as- 
sociated with a given received headerless data packet. 



A data packet having a compressed header is sent pe- 
riodically over the synchronized wireless link. The data 
packet having the compressed header can also be sent 
when the compressor detects changes in slowly-varying 
header fields , in response to feedback received from the 
decompressor indicating that a decompression context 
is out of synchronization and/or just before talk spurts 
occur. 
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Des ription , 
RELATED APPLICATIONS j 

i 

5 [0001] This patent application claims the benefit of priority from and incorporat s by reference the entire disclosure 
of co-pending U.S. Provisional Patent Application No. 60/250,253, filed on November 30, 2000. 

BACKGROUND 

10 [0002] In recent years, two communication technologies in particular have become commonly used by the general 
public: (1 ) mobile telephones; and (2) the Internet. Mobile telephones have provided users with the potential to always 
be reachable with reasonable service quality no matter where they are located. However, until recently, the primary 
service provided by mobile telephones has been speech. In contrast, the Internet has primarily provided data services. 
While flexibility for different services has been one of the Internet's strengths, the quality of services, such as, for 

15 example, Internet Telephony, has generally been unacceptable. 

[0003] However, Internet Protocol (IP) Telephony has been gaining momentum thanks to recent technological ad- 
vances. It is reasonable to predict that in the future, IP will become a commonly-used method of carrying telephony. 
Mobile telephony links could be based on IP telephony. In addition, mobile stations may also support not only audio 
and video, but also web browsing, e-mail, and gaming, for example. When IP telephony is employed, it is obvious that 

20 a fixed network at which wireless links terminate can be IP-based. 

[0004] IP could be terminated at the interface between the fixed network and wireless links connected thereto; how- 
ever, this would require special solutions to be implemented for each service supported over the wireless links. The 
flexibility of the services supported by the wireless links would therefore be limited. Thus, a solution implementing IP 
all the way from mobile station to mobile station over wireless links would have certain advantages. 

25 [0005] Spectral efficiency is one of the main problems that must be overcome in order to implement IP from mobile 
station to mobile station over wireless links. It is of vital importance to use the scarce radio resources in a wireless 
network as efficiently as possible. One of the problems with use of IP over wireless links in the context of interactive 
voice conversations is large header overhead. 

[0006] Speech data for IP telephony is most likely carried by the Real-time Transport Protocol (RTP). In RTP, apacket 
30 has, in addition to link layer framing, an IP version 4 header of 20 octets (i.e;, 160 bits), a Universal Datagram Protocol 
(UDP) header of 8 octets, and an RTP header of 12 octets, resulting in atotal header overhead of 40 octets. With IP 
version 6, the IP header is 40 octets, resulting in a total of 60 octets of total header overhead. The size of the payload 
depends upon speech coding and frame sizes used and may be as little as 15-20 octets. 

[0007] The need to reduce header sizes for spectral-efficiency reasons is therefore apparent. Header compression 
35 is essential for providing spectrally-efficient voice over IP (VoIP) and multi-media services. Existing header compression 
schemes do not perform well over wireless links, primarily because of high error rates and long link round-trip times. 
Existing compression schemes include Compression RTP (CRTP), IP Header Compression (IPHC), and Point-to-Point 
Protocol Header Compression (PPPHC). 

[0008] In an effort to develop an improved header compression scheme, the Internet Engineering Task Force (IETF) 
40 created the RObust Header Compression (ROHC) working group. ROHC provides a header compression framework 
that includes improved robustness, transparency, and spectral efficiency for wireless networks. A non-transparent so- 
lution, referred to as Good Enough Header Compression (GEHCO), has also been proposed. GEHCO is intended to 
compress VoIP by removing all headers; however, GEHCO is unsuited for applications other than VoIP, such as, for 
example, multi-media and some related VoIP applications. Therefore, a general header compression framework, such 
45 as, for example, ROHC, that can accommodate a wide variety of applications that will exist in third generation wireless 
networks in a consistent yet customized fashion and under a unified framework is needed. 

[0009] However, in order to provide needed highly-spectrally-efficient VoIP services on existing wireless network 
radio bearers, ROHC needs to be extended with a scheme that provides further compression beyond that which is 
currently possible via ROHC. It would be desirable to increase the compression possible under ROHC to the point that 
50 VoIP and other IP-based services could be implemented over wireless links with the same efficiency as voice services 
are currently implemented over the wireless links in a circuit-switched mode. 

[0010] Referring nowto the FIGURES, FIGURE 3 is a block diagram that illustrates transmission of VoIP data packets 
in cdma2 000. A system 300 includes a mobile station ( MS) 302, a radio netwo rk (RN) 304, and a packet data service 

node (PDSN) 306. An arrow 308 representing a transmission path of data packets from the PDSN 306 to the MS 302 
55 is also shown. Although not xplicitly shown, it will be understood by those skilled in the art that a transmission path 

from the MS 302 to the PDSN 306 operates in a similar fashion to that described herein. 

[0011] IP/UDP/RTP data packets 310 are shown in FIG. 3 entering the PDSN 306 at a network layer via the internet 
protocol (IP). As shown by the arrow 308, the data packets 310 pass through the link layer ( .g., PPP) and a radio- 
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network-point-to-point protocol (R-P) interface before being transmitted over the RN 304. While in the RN 304, the 
data packets 310 pass through a Radio Link Protocol/Media Access Control (RLP/MAC) layer. From the RLP/MAC 
layer, the data packets 31 0 are received by the MS 302. At the MS 302, the data packets 31 0 pass through the RLP/ 
MAC layer, the link layer (e.g., PPP), and the network layer (via IP), befor emerging as UDP/RXP packets. 

5 [0012] In cdma2000, all data traffic, including VoIP data packets, uses the point to point protocol (PPP) as the link 
layer. Incdma2000, there is a strong need to support VoIP and header compression on currently-existing radio bearers, 
rather than devising or optimizing new radio bearers for purposes of VoIP. One of the limitations imposed by many 
existing cdma2000 radio bearers is the capacity of the radio bearers to carry a compressed or uncompressed head r. 
[001 3] There is accordingly a need for a method and system that permit compressed-header data packets to be sent 

10 overwireless links for applications such as, for example, VoIP, and that solve the above-mentioned and otherproblems 
associated with the prior art. 

SUMMARY 

15 [0014] A method of transmitting data packets over a synchronous wireless link includes sending a headerless data 
packet on the synchronous wireless link. A sequential timer-based value is associated with the headerless data packet. 
The headerless data packet is received from the synchronous wireless link. The header of the headerless data packet 
is decompressed based at least in part on the sequential timer-based value associated with the received headerless 
data packet. The steps of sending the headerless data packet, receiving, and decompressing are repeated at least 

20 once. A data packet having a header is sent on the synchronous wireless link. 

[0015] A system for sending and receiving data packets includes a first node, a second node, and a synchronous 
wireless link. The first node is adapted to send a headerless data packet toward the second node via a synchronous 
wireless link. A sequential timer-based value is associated with the headerless data packet. The first node is also 
adapted to send a data packet having a header on the synchronous wireless link. The second node is adapted to 

25 receive the headerless data packet via the synchronous wireless link and decompress, based at least in park on the 
sequential timer-based value associated with the received headerless data packet, a header of the received headerless 
data packet, the second node is also adapted to receive the data packet having the header. The synchronous wireless 
link is between the first node and the second node. 

[0016] A node in a wireless communication system includes a transmitter adapted to send a first headerless data 
30 packet via a synchronous wireless link. A sequential timer-based value is associated with the headerless data packet. 
The transmitter is also adapted to send a first data packet having a header on the synchronous wireless link. The node 
also includes a receiver adapted to receive a second headerless data packet via the synchronous wireless link and 
receive a second data packet having a header. The node also includes a decompressor adapted to decompress, based 
at least in part on the sequential timer-based value associated with the first headerless data packet, the header of the 
35 first headerless data packet. w.r^ r 

[0017] A method of transmitting a header update includes checking a packet payload size and determining whether 
the packet payload size permits transmission of a header with the packet. In response to a determination that the 
packet payload size permits transmission of a header with the packet, a header with the packet is transmitted. In 
response to a determination that the packet payload size does not permit transmission of a header with the packet, a 
40 headerless data packet is transmitted. 

[0018] A method of transmitting a header update includes delaying a sequence of data packets and determining 
whether the delayed sequence of data packets comprises a talk spurt. In response to a determination that the delayed 
sequence comprises a talk spurt, a header update is transmitted prior to transmission of the delayed sequence of data 
packets. 

45 [0019] A method of transmitting a header update includes transmitting a sequence of data packets and determining 
whether at least one property of the transmitted sequence of data packets predicts a talk spurt. In response to a 
determination that the at least one property of the transmitted sequence predicts a talk spurt, a header update is 
transmitted prior to transmission of a first data packet of the predicted talk spurt. 

50 BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] A more complete understanding of the present invention can be had by reference to the following Description 
when taken in co njunction with the accom panying Drawings, wherein: j 

55 FIGURE 1 (a) is a diagram that illustrates a first exemplary periodic update scheme in accordance with principles 

of the present inv ntion; 

FIGURE 1 (b) is a diagram that illustrates a second exemplary periodic update scheme in accordance with principles 
of the present invention; 
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FIGURE 2 is a flow diagram that illustrates a flow for performing periodic updates in accordance with principles of 
the present invention; 

FIGURE 3, previously described in part, is a block diagram that illustrates transmission of Voice over IP data 
packets in cdma2000 in accordance with principles of the present invention; 

FIGURE 4 is a block diagram that illustrates a system in accordance with principles of th present invention in 
which a PPP-free connection between a Packet Data Service Node and an mobile station can be attained; and 
FIGURE 5 is a diagram that illustrates how maximal sizes of compressed headers can be derived assuming Se- 
lectable Mode Vocoder payload sizes and a 9.6 kbps fundamental channel radio bearer in cdma2000 in accordance 
with principles of the present invention. 

DETAILED DESCRIPTION Of THE DRAWINGS 



-r 

i 



[0021] In the following Detailed Description of the Drawings, for purposes of explanation and not limitation, specific 
details are set forth in order to provide a thorough understanding of embodiments of the present invention. However, 

15 it will be apparent to those of ordinary skill in the art that the present invention can be practiced in other embodiments 
that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, etc. 
/are omitted so as not to obscure the description of the present invention with unnecessary detail. Preferred embodi- 
ments of the present invention and its advantages are best understood by referring to FIGURES 1 -5 of the Drawings, 
like numerals being used for like and corresponding parts of the various Drawings. 

20 [0022] Aspects of cdma2000 will be used to describe preferred embodiments of the present invention. However, it 
should be understood that the principles of the present invention are applicable to other wireless communication sys- 
tems, especially those in which a slotted synchronous channel is used. 

[0023] In orderto provide highly spectrally-efficient multi-media services, such as, for example, Voice over IP (VoIP), 
on existing wireless radio bearers, embodiments of the present invention extend RObust Header Compression (ROHC) 

25 with a scheme that provides headerless (i.e., zero byte) header compression. A ROHC-compatible zero byte profile is 
used in accordance with preferred embodiments of the present invention. The zero byte profile permits headerless 
data packets to be transmitted over wireless links during a majority of the time that data packets are being transmitted 
over the wireless links. Underlying link and physical layers are relied upon to regenerate some of the fields of the 
header. Unlike Good Enough Header Compression (GEHCO), the zero byte profile used in accordance with embodi- 

30 ments of the present invention comprises additional mechanisms that ensure transparency, robustness, and reliabl 
operation, which are achieved by sending data packets having a header on a periodic and/or as-needed basis as 
header updates. Flexibility to wireless network operators is also provided by embodiments of the present invention, so 
that the wireless network operators can make necessary trade-offs between transparency, robustness, reliability, and 
spectral efficiency. 

35 [0024] ROHC is an Internet Engineering Task Force (IETF) header compression framework that provides for high 
efficiency and robustness as required in, wireless networks. ROHC has a number of benefitsand advantages -ROHC 
currently supports Real-time Transfer Protocol/Universal Datagram Protocol/Internet Protocol (RTP/UDP/IP) and UDP/ 
IP compression profiles. ROHC also includes planned support for a Transmission Control Protocol/Internet Protocol 
(TCP/IP) compression profile. 

40 [0025] ROHC has very high spectral efficiency. ROHC is transparent, which means that ROHC is able to generate 
semantically-identical headers. ROHC also exhibits robustness, which is defined as the ability to tolerate errors on the 
wireless links. ROHC is useable with multi-media applications and provides a single header compression framework 
for various applications, protocols, and wireless technologies. 

[0026] ROHC is currently capable of producing a plurality of compressed header types having different sizes. These 
45 compressed header types include packet type 0 (UO-1 , 1 byte), packet type 1 (UO-1 , 2 bytes), packet type 2 (UO-2, 
3 bytes plus extension), packet type 5 (IR, approximately 40 bytes and used to send an initial IP/UDP/RTP header), 
packet type 6 (IR-DYN, approximately 20 bytes), feedback-1 (1 byte), and feedback-2 (at least 2 bytes). In accordance 
with the principles of the present invention, the zero byte profile includes a new packet type having zero bytes. The 
zero byte profile uses one or more of the above header packet types in orderto support updating strategies in accord- 
50 ance with principles of the present invention. The zero byte profile used in accordance with embodiments of the present 
invention also imposes a limit on the maximal header size that can be accepted. 

[0027] The ROHC compression/decompression operation comprises the following: (1) a compressor constructs a 
compressed heade r that includes encode d versions of some of the original RTP/UDP /IP fields and also inc ludes a 
cyclical redundancy check (CRC) that is computed on the full original header; (2) a decompressor uses a current stat 
55 (i.e., the context) and the encoded fields of the compressed header in order to produce a decompressed header. A 
context is a state that the compressor uses to compress a header and that the decompressor uses to decompress th 
header. The context is in essence an uncompressed version of the last header sent by the compressor or received by 
the decompressor over the wireless link, except for fields in the header that are included as-is in compressed headers 
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or can be inferred from, for example, the size of a link-level frame. The context can also contain additional information 
describing a data packet stream, such as, for example, typical inter-packet increase In sequence numbers or time 
stamps. 

[0028] By r calculating the CRC of the decompressed header and comparing it to the r ceived CRC, the decom- 
5 pressor can verify wh ther the process of compression/decompression is transparent and has been succ ssful. The 
size of the compressed header varies depending upon the dynamics of the header compression. ROHC currently 
provides for header sizes as small as 1 , 2, and 3 bytes, which are the sizes used most often by ROHC. 
[0029] The existing ROHC profiles are designed to work well over wireless links without imposing restrictive require- 
ments or making specific assumptions regarding underlying architectural, design, or implementation properties of the 
10 links. However, some systems have properties that can be advantageously exploited with respect to header compres- 
sion. Embodiments of the present invention exploit the flexibility of ROHC in order to capitalize on such properties by 
defining a new profile. 

[0030] The headerless (i.e., zero byte) profile is preferably used when an underlying link layer comprises a synchro- 
nous slotted channel (e.g., 20 ms frames), play-out buffers are employed, and timer-based cornpression/decompres- 
*s sion is used. In a preferred embodiment, the zero byte profile can be used to compress traffic in which VoIP traffic is 
present, sequential or sequential-jump IP Identifier (IPID) assignment is used, and there is no IP fragmentation or UDP 
check sum. 

[0031] In the event that some of the above characteristics cannot be satisfied, a filter can be added before the 
compressor in order to map changing fields into new ones that can be supported by the zero byte profile. For exampl , 
20 if the IP Identifier (IP-ID) field is randomly assigned, the filter can change the randomly-assigned IP-ID values into 
sequentially-assigned ones before the headers are supplied to the compressor. 

[0032] In order to send zero byte compressed headers (i.e., headerless data packets) during the bulk of the com- 
pressor's operation time, the zero byte profile exploits the characteristics described above. The zero byte profile reMes 
on proper buffering and ordering of data packets (e.g., IP/UDP/RTP packets) and timer-based decompression ta re- 

25 g nerate a dynamic part of the header (e.g., RTP Sequence Number (RTP SN), RTP Timestamp (RTP TS), or IP=ID). 
In order to maintain transparency of the header compression and compressor-decompressor synchronization, embod- 
iments of the present invention from time to time send a data packet having a header, referred to as a header update. 
The data packet that includes the updated header can include a compressed or an uncompressed header, but is 
preferably a ROHC compressed header. 

30 [0033] One or more strategies can be employed by the compressor in accordance with embodiments of the present 
invention in order to ensure transparency by sending header-update data packets having either compressed or un- 
compressed headers. Header updates are preferably performed using ROHC compressed headers. First, header up- 
dates can be sent on a periodic basis. A periodic update mechanism is used that is flexible and aware of link and 
physical layer limitations of the wireless link over which the data packets are sent. Header updates can also be sent 

35 when the compressor detects changes in slowly-varying original header fields or in response to feedback received 

from the decompressor, such as, for example, when a decompression context is out of synchronization.- Compressed ■»■ 

headers can also be sent just before talk spurts occur. 

[0034] FIGURES 1(a) and 1(b) are diagrams that illustrate two exemplary periodic update schemes that can be 
implemented in accordance with the principles of the present invention. FIGURE 1 (a) illustrates a scheme in which a 

40 compressor attempts to send a data packet having a header every T packets or time units. Depending upon the size 
of the payload and data packet size, the compressor may or may not be able to send a header with a particular packet. 
[0035] Performing periodic header updates by sending a data packet that has a compressed or an uncompressed 
h ader is one of the techniques that can be used in accordance with the principles of the present invention to ensure 
transparency and robustness of the zero byte profile. It is preferable that the header update use a compressed rather 

45 than an uncompressed header. Although use of periodic updates is already defined by ROHC, the zero byte profile 
used in accordance with principles of the present invention provides additional flexibility to the periodic updating schem 
beyond that possible with ROHC. The period, as well as other parameters, of the periodic update mechanism is flexible 
and negotiable. Wireless network operators have full control in configuring parameters of the periodic update mecha- 
nism in ways that meet their transparency and robustness requirements. 

so [0036] Under certain circumstances, radio-bearer limitations may mandate that a compressed or uncompressed 
header cannot be sent with a particular data packet. For example, the compressor may determine that it cannot send 
a header with a given packet because the payload size is too great. In such a situation, the flexible header update 

technique in accordance with embodiments of the pres ent invention does not re quire a strict time period within which 

to send the data packet having a header, but rather allows a time interval to achieve the header update. 

55 [0037] Referring again to FIGURE 1(a), at T, the compressor attempts to send a data packet having a header, as 
illustrated by arrow 1 02. The head r update preferably uses a ROHC compressed header. The compressor continues 
to try to send a data packet having a header until a time that is less than T + a, represented by arrow 1 04, is reached, 
at which time the compressor is successful in sending a data packet having a header as a header update. Time T+a 
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represents a trial interval, at the end of which, if the compressor is unable to send a data packet having a header as 

a header update, the compressor quits trying to send a data packet having a header as a header update. 

[0038] At time 2T, the compressor again begins to attempt to send a data packet having a header as a header update. 

The header update preferably uses a ROHC compressed header. The compressor successfully s nds the header 
5 update before 2T + a is reached, as illustrated by arrow 1 06. At time 2T + a, the trial interval corresponding to time 2T 

ends. At time 3T (not shown), the compressor again begins to attempt to send a header update. 

[0039] As an alternative to the mechanism described in FIGURE 1 (a), at the end of the trial interval (e.g., T + a), the 

compressor can use blank-and-burst (i.e., speech blanking) to send the header update instead of all or part of the 

payload associated with a given packet, if the compressor is not otherwise able to perform the header update. Blank- 
10 and-burst is not a preferred method of performing the header update, because it inherently requires a loss of data 

packet payload and therefore likely requires that voice quality over the wireless link be impaired during the time that 

the blank-and-burst occurs. 

[0040] FIGURE 1 (b) illustrates an alternative header update scheme in accordance with principles of the present 
invention. In FIGURE 1 (b), the compressor begins to attempt to send a data packet having a header at T packets or 

15 time units. The header update preferably uses a ROHC compressed header. The compressor will keep attempting to 
perform a header update until it is successful, as illustrated by arrow 108 at T + c. After the header update is successfully 
performed at T + c, a new starting point for the period T is begun, such that, at time 2T + c, the compressor begins 
again to attempt to perform a header update. At arrow 110, a second data packet having a header, preferably a ROHC 
compressed header, is successfully sent. 

20 [0041] During a talk spurt, data packets of maximal payload size typically persist over a significant duration of tim 
Therefore, the radio bearer is constrained to carrying maximal payload and may not be capable of carrying data packets 
having headers during the time that the talk spurt occurs. A mechanism that addresses talk spurts and which, in a 
preferred embodiment, may be activated or deactivated by a wireless network operator, predicts or detects a beginning 
of a talk spurt and sends a data packet having a header, preferably a ROHC compressed header, just before the talk 

25 spurt begins. 

[0042] When prediction of the talk spurt is implemented, the compressor determines the properties of an incoming 
sequence of data packets that have already been transmitted by the compressor. Using at least one property of these 
previously transmitted data packets, the compressor predicts the properties of incoming packets. When the predicted 
properties of the incoming data packets indicate that they comprise a talk spurt, a data packet having a header is 

30 transmitted prior to the first data packet of the predicted talk spurt. 

[0043] When detection is used by the compressor, the compressor delays and/or buffers, but does not transmit, a 
given data packet until a subsequent sequence of data packets have been received and examined in order to determine 
whether a talk spurt is occurring. If the subsequent sequence of data packet indicates a talk spurt, a data packet having 
a header is transmitted prior to the first data packet comprising the talk spurt. In a preferred embodiment, the detection 

35 mechanism is used, since the zero byte profile preferably employs a.playout buffer in order to avoid compression 
problems due to downlink jitter. In this embodiment, an uplink buffer is also needed. 

[0044] A data packet having a header can also be sent by the compressor in order to indicate changes in slowly- 
varying fields of the header. This option can preferably be activated/deactivated by anetwork operator. Negative feed- 
back can also be sent from the decompressor to the compressor to indicate that the decompression context Is invalid. 
40 in response to such feedback, the compressor can send header updates. This option can also, in a preferred embod- 
iment, be activated or deactivated by wireless network operators. 

[0045] Any combination of the various header updating techniques described herein can be employed in accordance 
with the principles of the present invention. For example, a single header can be sent that serves as a feedback re- 
sponse as well as a periodic update. 

45 [0046] FIGURE 2 is a flow diagram that illustrates a flow 200 that can be used by the compressor when the com- 
pressor sends a periodic update. The flow 200 begins at step 202. At step 202, a timer (or, alternatively, a packet 
counter) is set to zero and is started running. At step 204, a determination is made whether a target value (e.g., a 
specified time or number of packets) has been reached. If it is determined at step 204 that the target has been reached, 
execution proceeds to step 206. If, at step 204, it is not determined that the target has been reached, execution moves 

50 to step 204. 

[0047] At step 206, a payload size of a current packet is checked by the compressor. The payload size is checked 
so that the compressor can in later steps determine whether there is room for inclusion of a header in the data packet 
so that a header up date can be performed. From step 206, ex ecution proceeds to step 208. At step 208, a determination 
is made whether a header can be sent with the current data packet. In other words, the compressor determines whether 
55 there is enough room in the frame to include a header along with the payload. 

[0048] If it is determined at step 208 that a header can be sent with the current data packet because there is room 
in the fram for a header to be included, execution proceeds to step 21 0. At step 21 0, a non-zero-byt header update 
is sent with the current data packet as a header update. From step 210, execution moves to step 202. If it is not 
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determined at step 208 that a header canbe sent with the current data packet, execution proce ds to step 212. Atst p 
212, a zero byte head r is sent with the current data packet. In other words, at step 212, a headeriess data packet is 
sent by the compressor. From step 212, execution moves to step 206. Although in FIG. 2, each subsequent packet is 
checked in order to determin whether a header update can be performed, more than on packet can be.transmitted 

5 with a zero-byte header before a subs quent pack t is check d. 

[0049] FIGURE 2 illustrates that the compressor periodically checks the current data packet payload size and, if 
possible, sends a data packet having a header as a header update. The header update preferably uses a ROHC 
compressed header. If the current data packet does not permit a data packet having a header to be sent as a header 
update, the compressor continues to check each subsequent data packet's size until it finds a data packet that permits 

10 a header update to be sent. In the interim while the compressor is checking for a data packet that will permit a header 
update to be sent, the compressor continues to send headeriess data packets. 

[0050] Exemplary embodiments of the present invention adapted to be used on cdma2000 radio bearers will now 
be described. However, it should be understood by those having ordinary skill in the art that the principles of the present 
invention are not limited to cdma2000, but rather can be implemented on many different wireless radio bearers, such 
is as, for example, GSM/GPRS (with or without EDGE), WCDMA, andTDMA (IS-136). Moreover, even though two nodes 
are represented herein as an exemplary mobile station and packet data service node, it will be understood by thos 
skilled in the art that various nodes can operate according to principles of the present invention, such as, for example, 
base stations, mobile switching centers, and the like, and that the nodes can but need not be located at termination 
points of fixed networks. 

20 [0051 ] The Selectable Mode Vocoder (SMV) used in cdma2000 has a payload that is targeted towards a fundamental 
channel having a maximum rate of 9.6 kbps. Therefore, in the examples below, the fundamental channel having a 
maximum rate of 9.6 kbps is used for carrying VoIP payload plus headers. A comparison of different available SMV 
payload sizes against various fundamental channel multiplexing formats reveals that the fundamental channel can 
carry a compressed header whenever less-than-fuil-rate SMV voice frames are produced. 

25 [0052] In cdma2000, compressed headers cannot be sent for every possible VoIP data packet because sometimes 
the payload size relative to the frame size does not leave enough room to carry compressed headers. For example, 
when VoIP data packet payload is 1 70 bits, a compressed header cannot be transmitted and only VoIP payload can 
be sent in a 20 ms frame. In such a situation, biank-and-burst (i.e., speech blanking) can be used to send a compressed 
header, without any payload being sent in the data packet. Dim-and-burst could also be used; however, dim-and-burst 

30 is not as desirable as blank-and-burstbecause dim-and-burst requires a signal from the decompressor to the compres- 
sor that explicitly requests a lower frame rate: 

[0053] Even in cases in which there is enough room in the 9.6 kbps fundamental channel to carry a compressed 
header, headers should not be sent unless necessary, in order to maximize the spectral efficiency of the wireless link. 
Therefore, in accordance with principles of the present invention, a mechanism is defined for sending data packets 
35 with headers as header updates. The header update techniques described herein can be used either singly r or in 
combination with another. 

[0054] Headers decompressed at the decompressor must be identical to the original headers within a reasonable 
probability. In other words, the IETF transparency and robustness requirements mustbe attained. The update mecha- 
nisms described herein provide the necessary tools to achieve the goals of transparency and robustness. Full flexibility 
40 is given to cdma2000 operators so that they can decide how to balance transparency and robustness against spectral 
efficiency. 

[0055] Table 1 illustrates the structure of the 9.6 kbps fundamental channel in cdma2000. At 9.6 kbps, the funda- 
mental-channel frame includes primary traffic, signaling traffic, and secondary traffic. Within the 9.6 kbps fundamental- 
channel frame, primary traffic can carry voice payload of 1 71 , 80, 40 or 1 6 bits. Signaling traffic can carry 88, 128, 152, 

45 or 168 bits. Secondary traffic can carry 88, 128, 152, or 168 bits. MM designates mixed mode, which is a qualifier of 
whether concurrent traffic types are sent in the frame. Zero means that only one type (i.e., primary) and one means 
that two different traffic types (i.e., either primary and secondary or primary and signaling). TT designates the traffic 
type. If MM is one, TT distinguishes the second traffic type as being either secondary or signaling traffic. TM designates 
the traffic mode. When two traffic types are sent in the frame, TM qualifies/identifies the bit rate of each traffic type in 

50 the frame. 



55 
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Table 1 
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[0056] If a data packet having a compressed header is to be sent as primary traffic, the compressed header is 
preferably added to the voice payload and the total number of bits in the primary traffic fundamental-channel frame is 
increased to the next level. A unique-leading data sequence can be defined within the primary traffic frame in order to 
indicate whether the frame is or is not carrying voice payload plus a header 

[0057] For example, if 40 bits of VoIP payload is being sent and a header needs to be sent in order to perform a 
header update, then the 80-bit primary traffic frame could be used and an 8-bit sequence of 11111111 used to indicate 
the presence of a header, two bits (e.g., 01) could be used to indicate that the voice payload size is 40 bits and not 16 
bits, the next 40 bits used as voice payload, and all or some of the remaining 30 bits used to hold the compressed 
header information. 

[0058] In the alternative, the VoIP data packet payload can be sent as primary traffic and the compressed header 
sent as signaling traffic. If de compressed header is sent as signaling traffic, synchronization is required to ensure that 
the VoIP payload and its compressed header are sent in the same 20 ms frame. Otherwise, the decompressor does 
not know how to associate the proper header with the proper payload. If this alternative is employed, the delay of 
primary traffic and signaling traffic in reaching the decompressor is assumed to be within an acceptable limit that 
enables resolution of header-pay load association without uncertainty. 

[0059] As another alternative, the compressed header can be sent as secondary traffic and the VoIP payload sent 
as primary traffic. Similar issues to those when the compressed header is sent as signaling traffic are present when 
the compressed header is sent as secondary traffic. ._ 

[0060] From a spectral efficiency perspective, sending the compressed header as primary traffic is preferable to 
sending the compressed header as signaling or secondary traffic, because sending the compressed header as sec- 
ondary or signaling traffic only permits transmission of a data packet having payload and a header using full-rate 
channel frames (i.e., 9.6 kbps). This is because when 4.8 kbps, 2.4 kbps, or 1.2 kbps rates are used, signaling and 
secondary traffic are not available, as shown in Table 1 . In contrast, when the compressed header is sent as primary 
traffic, 9.6 kbps, 4.8 kbps, 2.4 kbps or 1 .2 kbps rates can be used. 

[0061] In addition, when the compressed header is sent as primary traffic, the payload and header, including any 
unique leading sequence and payload size data, can be combined and formatted at the compressor without the physical 
or MAC layers being aware of the formatting or combination thereof. In contrast, when a compressed header is sent 
as signaling traffic or secondary traffic, a mechanism that guarantees transmission ofthe payload and its associated 
header during the same 20 ms frame is necessary. A mec hanism to guarantee this association during the same 20 
ms frame introduces additional complexities not present when the compressed header is sent as primary traffic. 
[0062] If the compressor is closely tied to the physical layer and therefore does not use compressed headers, sending 
the compressed header as primary traffic typically requires a filter to reverse modifications made to the voice payload 
format, such as, for example, modifications that would permit the compressor to be aware of changes introduced by 
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header compression. 

[0063] In 0010182000, all data traffic, including VoIP data packets, uses the point to point protocol (PPP) as the link 
layer. Because there is a strong need in cdma2000 to support VoIP and header compression on currently-existing radio 
bearers, rather than devising or optimizing n w radio bearers for purposes of VoIP, in accordanc with principles of 

5 th present invention, ROHC can be extended to support the needs of VoIP and related services in cdma2000. 

[0064] Embodiments of the present invention permit support of header compression on xisting cdma2000 radio 
bearers, such as, for example, the bearer illustrated in FIG. 3, that have not been optimized for VoIP. Limitations 
imposed by these existing cdma2000 radio bearers can influence operation of the above-described techniques for 
sending data packets having headers as header updates; therefore, limitations of the existing cdma2000 radio bearers 

10 are taken into account. 

[0065] One of the limitations imposed by many existing cdma2000 radio bearers is the capacity of the radio bearers 
to carry a compressed or uncompressed header. In order to deal with these limitations, embodiments of the present 
invention include a mechanism that can dynamically determine radio-bearer limitations or constraints and adapt the 
header-updating techniques to overcome these radio-bearer limitations. The ability of embodiments of the present 
is invention to dynamically learn of the radio-bearer constraints is preferably performed on a data-packet-by-data packet 
basis. 

[0066] Radio-bearer limitations can be communicated to the compressor via explicit signaling from another entity, 
such as, for example, a MAC. Signals from the MAC to the compressor indicate to the compressor whether the radio 
b arer is capable of carrying a compressed or an uncompressed header, and, if so, a maximally-sized header that can 
20 b carried by the radio bearer. However, if the compressor and the radio bearer are not located within the same node, 
explicit signaling can introduce additional complications. 

[0067] In a preferred embodiment, the compressor includes logic that permits a determination to be made of the size 
of the payload of the data packet and a comparison to be made of this payload size against a locally-defined mapping, 
which can be in the form of, for example, a table. The mapping indicates whether a compressed or uncompressed ±i 

25 header can be sent on the radio bearer, and, if so, the maximal size of the header that can be sent. The mapping logic 
is implemented in preferred embodiments of the present invention because it is localized in the compressor and does 
not require signaling or other interaction between the compressor and other entities. Rather, the mapping logic achieves 
the goal of providing header updates by examining the payload size and consulting a locally defined mapping. ' 
[0068] Referring again to FIGURE 3, also shown is the overhead associated with PPP, IP, UDP, RTP, and voice 

30 payload. The overhead of full IP/UDP/RTP and PPP headers is very substantial, in that it equals 42 octets (i.e., 336 
bits). Given a 2.0 ms frame and a 9.6 kbps fundamental channel, it is impossible to fit the 212-octet overhead into a 
single frame, since a maximum of 1 92 bits can be transmitted in a single frame. Thus, there is a need to avoid the PPP 
overhead in addition to the need for ROHC IP/UDP/RTP header compression. 

[0069] FIGURE 4 is a block diagram that illustrates a system in accordance with principles of the present invention 

35 in which a so-called PPP-free connection between a PDSN and an MS can be attained. In addition to the RN 304; the 
IP/UDP/RTP data packets 31 0, and the arrow 308 illustrated in FIGURE 3, FIGURE 4 also shows, as part of a system 
400, an MS 404 and a PDSN 406. The MS 404 includes a decompressor 408, while the PDSN 406 includes a com- 
pressor 410. In addition, a dashed arrow 402 illustrates a PPP-free connection between the PDSN 406 and the MS 
404. Although not explicitly shown, it will be understood by those skilled in the art that a transmission path from the 

40 MS 404 to the PDSN 406 operates in a similar fashion to that described herein. 

[0070] The PPP-free connection is described in GEHCO contributions to IETF and permits establishment of a second 
R-P session that is connected to a null-RLP (e.g. , RLP 2) in the RN 304. The system 400 can be adopted for applications 
in which spectral efficiency is especially important and in which the two-octet (i.e., 16 bit) PPP overhead introduces 
significant spectral efficiency losses, such as, for example, in VoIP. 

45 [0071 ] In a preferred embodiment of the present invention, the PPP-free connection between the PDSN 406 and the 
MS 404 is used for VoIP. Other packet data applications, such as, for example, IP multimedia (IPMM) typically use a 
regular connection that includes PPP, as illustrated by the arrow 308. This is because in IPMM, spectral efficiency is 
only marginally affected by the PPP overhead, since IPMM applications use much larger payload sizes than VoIP. 
[0072] FIGURE 5 is a diagram that illustrates how maximal sizes of compressed headers can be derived assuming 

so SMV payload sizes and a 9.6 kbps fundamental channel radio bearer in cdma2000 in accordance with principles of 
the present invention. FIGURE 5 assumes that a PPP-free connection is used, as indicated by the starburst in the 
column pertaining to PPP overhead. It is also assumed that the compressed header is sent as primary traffic and that 
the zero byte profile in accordance with principles of the present inve ntion is used. As show n in FIG. 5, a 171 bit frame 
can accommodate a maximal header size of 1 55, 1 31 , or 91 bits for voice payload sizes of 1 6, 40, and 80 bits, respec- 

55 tively. In a similar fashion, if an 80 bit frame is used, a maximal header size of 64 or 40 bits can be accommodated for 
voice payloads of 16 or 40 bits, respectively. Furth r, if a 40 bit frame size is used, a maximal header size of 24 bits 
can be accommodated when a 16 bit voice payload is used. Thus, it can be seen that a 40, 80, or 171 bit frame can 
be used to send compressed headers in cdma2000 in accordance with the principles of the present invention. 
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[0073] A mapping (e.g., a table) can be used to implement additional logic required by, for example, the compressor 
41 0, to determine limitations of the 9.6 kbps fundamental channel radio bearer shown in FIGURE 5. The compressor 
410 examines the payload size, looks at an appropriate table row, and determines if the compressor 410 can send a 
header along with the current data packet, and if so, the preferred size of the head r to be included in the curr nt data 
packet. Table 2 is an xemplary table used by, for example, the compressor 41 0. 

Table 2 



Local Table (Mapping) used at the Compressor 


Payload 
Size 


Can Send 
Header? 


Preferred Max 
Header Size 


2 nd Preferred Max 
Header Size 


3 rd Preferred Max 
Header Size 


171 


NO 








80 


YES 


91 bits 






40 


YES 


40 bits 


131 bits 




16 


YES 


24 bits 


64 bits 


155 bits 



10 



15 



20 



25 



30 



35 



Table 2 shows that, for a payload size of 171 bits, a header cannot be sent. For a payload size of 80 bits, a header 
can be sent and the preferred maximal header size is 91 bits. For a payload size of 40 bits, a header can be sent and 
the preferred maximal header size is 40 bits, a second preferred maximal header size being 131 bits. For a payload 
size of 16 bits, a header can be sent and the preferred and maximal header size is 24 bits, the second preferred 
maximal header size is 64 bits, and the third preferred maximal header size is 155 bits. 

[0074J Header updates as described herein can be easily implemented for the cdma2000 SMV compressor, by having 
the compressor and delay and/or buffer a first packet until one or more subsequent data packets arrives and is exam- 
ined. If the size of the subsequent packet's payload is 171 bits, a header is created for the first packet and transmitted 
along with the first data packet. 

[0075] Full flexibility is provided to cdma2000 operators in order to achieve their spectral efficiency targets through 
the ability to activate or deactivate the periodic update mechanism and to set or negotiate the flexible period of the 
periodic update mechanism. In addition, spectral efficiency targets can be achieved through the use of activation or 
deactivation of updating of slowly-varying header fields and of sending of updates in response to feedback. Any of the 
above-mentioned mechanisms can be used in various combinations according to wireless network operator's objec- 
tives. 

[0076] Although embodiment(s) of the present invention have been illustrated in the accompanying Drawings and 
described in the foregoing Detailed Description, it will be understood that the present invention is not limited to th 
embodiment(s) disclosed, but is capable of numerous rearrangements, modifications, and substitutions without de- 
partment from the invention defined by the following claims. 



40 



Claims 

1 . A method of transmitting data packets over a synchronous wireless link comprising: 



45 



50 



sending a headerless data packet on the synchronous wireless link, a sequential timer-based value being 
associated with the headerless data packet; 

receiving the headerless data packet from the synchronous wireless link; 

decompressing, based at least in part on the sequential timer-based value associated with the received head- 
ertess data packet, the header of the received headerless data packet; 

repeating at least once the steps of sending the headerless data packet, receiving, and decompressing; and 
sending a data packet having a header on the synchronous wireless link. 

2. The method of claim 1 , further comprising assessing radio-bearer limitations of the synchronous wireless link. 



55 



3. — T he m ethod o f claim 2 ; wherein the step of assessing further comprises-d e t e rmini n g w rrethera size of the payload 

will permit a data packet having a header to be sent on the synchronous wireless link. 

4. The m thod of claim 3, wherein th step of assessing further comprises determining a maximally-sized header 
that can be sent on the synchronous wireless link. 
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5. The method of claim 3, wherein the period of sending of the data pack t having the header varies in response to 
the step of determining whether the size of the payload will permit a data packet having a header to be sent on 
the synchronous wireless link. 

5 6. Th method of claim 2, wher in the step of ass ssing is performed on a data-packet-by-data-packet basis. 

7. The method of claim 1 , wherein the step of sending the data packet having the header is performed due to a talk 
spurt. 

10 8. The method of claim 7, wherein the data packet having the header comprises a compressed header. 

9. The method of claim 1 , wherein the data packet having the header comprises a compressed header. 

10. The method of claim 1 ; wherein the method operates according to at least one of GSM/GPRS, WCDMA, cdma2000, 
15 andTDMA(IS-136). 

11. The method of claim 7, further comprising: 

analyzing properties of a plurality of previously-sent data packets; 
20 based on the analysis, predicting that a talk spurt is about to occur; and 

wherein the step sending the data packet having the header on the synchronous wireless link is performed 
in response to the prediction. 

25 12. The method of claim 7, further comprising: 

buffering a plurality of data packets; 

examining the plurality of data packets to determine whether a talk spurt is occurring; and 

30 wherein the step of sending the data packet having the header on the synchronous wireless link is performed 

in response to a determination that a talk spurt is occurring and prior to sending of a first data packet including the 
talk spurt. 

13. The method of claim 1 , wherein the step of sending the data packet having the header is performed periodically. 
35 *r 

14. The method of claim 13, wherein the data packet having the header comprises a compressed header. 

15. The method of claim 13, wherein the step of sending the data packet having the header comprises: 

40 determining a maximally-sized header that can be sent on the synchronous wireless link; 

in response to a determination that no header can be sent, sending at least one headerless data packet; and 
in response to a determination that a data packet having a header can be sent, sending a data packet having 
a header not exceeding the maximally-allowable size. 

^5 16. The method of claim 1 , wherein the step of decompressing comprises timer-based decompression of at least one 
dynamic part of the header of the received headerless data packet. 

1 7. The method of claim 1 6, wherein the at least one dynamic part comprises at least one of an RTP Sequence Number, 
an RTP Timestamp, and an IP-Identifier. 

50 

18. The method of claim 1 , wherein the step of sending the data packet having the header is performed in response 
to a determination that a value of a slowly- varying field in a removed header has changed from an earlier value 
thereof. 



55 19. The method of claim 18, wherein th data packet having the head r comprises a compressed header. 

20. The method of claim 1 , wherein the step of sending the data packet having the header is performed in respons 
to feedback indicating that the sequential timer-based value associated with the received headerless data pack t 
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is not the sequential timer-based value expected. 

21. The method of claim 20, wherein the data packet having the header comprises a compressed header. 

5 22. The method of claim 1 , wherein the sequential timer-based value compris s at least one of an RTP Sequence 
Number, an RTP Timestamp, and an Internet protocol identifier. 

The method of claim 1 , further comprising removing a header from a data packet comprising a payload and the 
header, thereby creating a headerless data packet. 

the method of claim 1 , wherein the step of decompressing comprises timer-based decompression. 
25. The method of claim 1 , wherein the header is sent as primary traffic. 
is 26. The method of claim 1 , wherein the header is sent as signaling traffic. 

27. The method of claim 1 , wherein the header is sent as secondary traffic. 

28. A system for sending and receiving data packets comprising: 

20 

a first node adapted to: 

send a headerless data packet toward a second node via a synchronous wireless link, a sequential timer- 
based value being associated with the headerless data packet; and 
25 send a data packet having a header on the synchronous wireless link; and 

a second node adapted to: 

receive the headerless data packet via the synchronous wireless link; and 

decompress, based at least in part on the sequential timer-based value associated with the received 
30 headerless data packet, a header of the received headerless data packet; 

receive the data packet having the header; and 

a synchronous wireless link between the first node and the second node. 

29. The system of claim 28, wherein the first node is adapted to assess radio-bearer limitations of the synchronous 
35 wireless link. 

30. The system of claim 29, wherein the first node is adapted to determine whether a size of the payload will permit 
a data packet having a header to be sent by the first node on the synchronous wireless link. 

40 31 . The system of claim 30, wherein the first node is adapted to determine a maximally-sized header that can be sent 
by the first node on the synchronous wireless link. 

32. The system of claim 30, wherein the period of sending of the data packet having the header varies in response to 
the determination by the first node whether the size of the payload will permit a data packet having a header to be 

45 sent on the synchronous wireless link. 

33. The system of claim 29, wherein the assessment is performed on a data-packet-by-data-packet basis. 

34. The system of claim 28, wherein the first node is adapted to send the data packet having the header due to a talk 
50 spurt. 

35. The system of claim 28, wherein the system operates according to at least one of GSM/GPRS, WCDMA, 
cdma2000, and TDMA (IS-136). 



55 36. The system of claim 28, wher in the data packet having the header comprises a compressed header 

37. The system of claim 34, wherein the first node is further adapted to 

analyze properties of a plurality of previously-sent data packets; 



23. 

10 

24. 
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based on the analysis, predict that a talk spurt is about to occur; and 

send the data packet having the header on the synchronous wireless link in response to the prediction. 

38. The system of claim 34, wherein the first node is furth r adapted to: 

5 

buffer a plurality of data packets; 

examine the plurality of data packets to determine whether a talk spurt is occurring; and 
send the data packet having the header on the synchronous wireless link in response to a determination by 
the first node that a talk spurt is occurring and prior to sending by the first node of a first data packet including 
10 the talk spurt. 

39. The system of claim 28, wherein the data packet having the header is sent periodically. 

40. The system of claim 29, wherein the first node is further adapted to: 

15 

determine a maximally-sized header that can be sent on the synchronous wireless link; 
in response to a determination that no header can be sent, send at least one headerless data packet; and 
in response to a determination that a data packet having a header can be sent, send a data packet having a 
header not exceeding the maximally-allowable size. 

41. The system of claim 29, wherein the data packet having the header comprises a compressed header. 

42. The system of claim 28, wherein the first node comprises a base station adapted to operate according to global 
system for mobile communications (GSM) enhanced data for GSM evolution (EDGE). 

43. The system of claim 42, wherein the second node comprises a mobile station adapted to operate according to 
EDGE. 

44. The system of claim 28, wherein the first node comprises a base station adapted to operate according to tim - 
30 division-multiple access (TDM A). 

45. The system of claim 44, wherein the second node comprises a mobile station adapted to operate according to 
TDMA. 

35 46. The system of claim 28, wherein the decompression comprises timer-based decompression of at least one dynamic 
part of the header of the received headerless data packet. _ 

47. The system of claim 46, wherein the at least one dynamic part comprises at least one of an RTP Sequence Number, 
an RTPTimestamp, and an IP-Identifier. 

40 

48. The system of claim 28, wherein a connection between the first node and the second node is a PPP-free connection. 

49. The system of claim 48, wherein the PPP-free connection permits establishment of a second R-P session con- 
nected to a null-RLP over the synchronous wireless link. 

45 

50. The system of claim 28, wherein the first node comprises a mobile station adapted to operate according to 
cdma2000. 

51. The system of claim 28, wherein the second node comprises a mobile station adapted to operate according to 
50 cdma2000. 

52. The system of claim 28, wherein the first node comprises a packet data service node (PDSN) adapted to operate 
a ccording to cdma2000. 

55 53. The system of claim 28, wherein the second node comprises a packet data service node (PDSN) adapt d to 
op rat according to cdma2000. 

54. Thesystemofclaim28, wh r in the first node comprises a base station adapted to op rate according to cdma2000. 
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55. The system of claim 28, wherein the second node comprises a base station adapted to operate according to 
cdma2000. 

56. Th system of claim 28, wherein the sequential timer-based value comprises at least one of an RTP Sequence '\ ' r 
5 Numb r, an RTP Timestamp, and an Internet protocol identifier 

57. The system of claim 28, wherein the decompression comprises timer-based decompression. 5 

58. The system of claim 28, wherein the first node is further adapted to remove a header from a data packet comprising 
10 a payload and the header, thereby creating a headerless data packet. 

59. The system of claim 28, wherein the second node comprises a base station. 

60. The system of claim 28, wherein the first node comprises a mobile station. 

15 

61 . The system of claim 28, wherein the first node is adapted to send the data packet having the header in response 
to a determination that a value of a slowly-varying field in a removed header has changed from an earlier value 
thereof. 

20 62. The system of claim 61 , wherein the data packet having the header comprises a compressed header. 

63. The system of claim 28, wherein the first node is adapted to send the data packet having the header in response 
to feedback from the second node indicating that the sequential timer-based value associated with the received 
headerless data packet is not the sequential timer-based value expected by the second node. 

25 

64. The system of claim 28, wherein the header is sent as primary traffic. 

65. The system of claim 28, wherein the header is sent as secondary traffic. " 
30 66. The system of claim 28, wherein the header is sent as signaling traffic. 

67. The system of claim 63, wherein the data packet having the header comprises a compressed header. 

68. A node in a wireless communication system, the node comprising: 
a transmitter adapted to: - 



35 



send a first headerless data packet via a synchronous wireless link, a sequential timer-based value being 
associated with the headerless data packet; and 
40 send a first data packet having a header on the synchronous wireless link; 

a receiver adapted to: 

receive a second headerless data packet via the synchronous wireless link; and 
45 receive a second data packet having a header; and 

a decompressor adapted to decompress, based at least in part on the sequential timer-based value associated 
with the first headerless data packet, the header of the first headerless data packet. 

so 69. The node of claim 68, wherein the node is adapted to determine whether a size of the payload will permit the first 
data packet having a header to be sent by the node on the synchronous wireless link. 

70. The node of claim 69, wherein the node is adapted to determine a maximally-siz ed header that can be sen t by the 
node on the synchronous wireless link. 

55 

71 . Th node of claim 69, wherein the period of sending of the first data packet having the h ader varies in response 
to the determination by the node whether the size of the payload will permit a data packet having a header to be 
sent on th synchronous wireless link. 
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72. The node of claim 68, wherein the node is adapted to periodically s nd the first data packet having a header. 

73. The node of claim 68, wherein the node operates according to at least one of GSM/GPRS, WCDMA, cdma2000, 
and TDMA (IS-136). 

5 

74. The node of claim 68, wherein at least one of the first data packet having a header and the second data packet 
having a header is sent due to a talk spurt. 

75. The node of claim 68, wherein the first data packet having the header is sent in response to feedback indicating 
10 that the sequential timer-based value is not an expected sequential timer-based value. 

76. The node of claim 68, wherein the first data packet having the header is sent in response to a determination that 
a value of a slowly-varying field has changed from an earlier value thereof. 

15 77. The node of claim 68, wherein the second data packet having a header comprises a compressed header. 

78. The node of claim 68, further comprising a compressor adapted to remove a header from a data packet comprising 
a payload and the header, thereby creating the first headerless data packet. 

20 79. The node of claim 68, wherein the sequential timer-based value comprises at least one of an RTP Timestamp, an 
RTP Sequence Number, and an Internet protocol identifier. 

80. The node of claim 68, wherein the header is sent as primary traffic. 

25 81. The node of claim 68, wherein the header is sent as secondary traffic. 

82. The node of claim 68, wherein the header is sent as signaling traffic. 

83. A method of transmitting a header update comprising: 

30 

checking a packet payload size; 

determining whether the packet payload size permits transmission of a header with the packet; 
in response to a determination that the packet payload size permits transmission of a header with the packet, 
transmitting a header with the packet; 
35 in response to a determination that the packet payload size does not permit transmission of a header with the 

packet, transmitting a headerless data packet. 

84. The method of claim 83, wherein the step of checking is performed in response to expiration of at least one of a 
timer and a packet counter. 
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85. The method of claim 84, wherein at least one of the timer and the packet counter is reset and started in response 
to transmission of a headerless data packet. 

86. The method of claim 83, further comprising the steps of: 



determining whether the packet payload size of the subsequent packet permits transmission of a header with 
the subsequent packet; 

in response to a determination that the packet payload size of the subsequent packet permits transmission of 
a header with the subsequent packet, transmitting a header with the subsequent packet; 
so jn response to a determination that the packet payload size of the subsequent packet does not permit trans- 

mission of a header with the subsequent packet, transmitting a headerless data packet. 

87. The method of claim 83, wherein each of the steps of determining comprises comparing a packet payload size to 
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a frame size. 

88. The method of claim 83, further comprising th step of checking a packet payload siz of a subsequent packet in 
response to the step of transmitting the headerless data packet. 
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89. The method of claim 83, wherein the step of determining comprises comparing the packet payload size to a frame 
size. 

90. The method of claim 83, wherein the header comprises a compressed header. 

5 

91 . The method of claim 83, wherein the header is sent as primary traffic. 

92. The method of claim 83, wherein the header is sent as secondary traffic. 
io 93. The method of claim 83, wherein the header is sent as signaling traffic. 

94. A method of transmitting a header update comprising: 

delaying a sequence of data packets; 
15 determining whether the delayed sequence of data packets comprises a talk spurt; 

in response to a determination that the delayed sequence comprises a talk spurt, transmitting a header update 
prior to transmission of the delayed sequence of data packets. 
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95. The method of claim 94, further comprising transmitting the delayed sequence of data packets. 

96. The method of claim 94, wherein the talk spurt comprises a plurality of data packets having a maximal payload size. 

97. The method of claim 94, wherein the header update comprises a compressed header. 
25 98. The method of claim 94, wherein the header update comprises primary traffic. 

99. The method of claim 94, wherein the header update comprises secondary traffic. 

100. The method of claim 94, wherein the header update comprises signaling traffic. 
101 .A method of transmitting a header update comprising: 
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transmitting a sequence of data packets; 

determining whether at least one property of the transmitted sequence of data packets predicts a talk spurt; 
35 In response to a determination that the at least one property of the transmitted sequence predicts a talk spurt, 

transmitting a header update prior to transmission of a first data packet of the predicted talk spurt. 

102. The method of claim 1 01 , further comprising transmitting a plurality of data packets comprising the predicted talk 
spurt. 

40 

103. The method of claim 1 01 , wherein the predicted talk spurt comprises a plurality of data packets having a maximal 
payload size. 

104. The method of claim 101 , wherein the header update comprises a compressed header. 

45 

105. The method of claim 101 , wherein the header update comprises primary traffic. 

106. The method of claim 101, wherein the header update comprises secondary traffic. 
so 107 .The method of claim 101 , wherein the header update comprises signaling traffic. 
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